科普|凭证真假难辨，去中心化身份体系有妙招（三）

之前&＃xff0c;我们已连载翻译了 Rebooting Web of Trust 组织在 RWOT IX — Prague, 2019会议上的论文《Alice Attempts to Abuse a Verifiable Credential》&＃xff0c;了解了 Alice 是如何企图对其处方进行作恶的&＃xff0c;本期我们将连载最后一部分&＃xff0c;向大家阐述作为验证者要如何防止遭受恶意证书持有者的欺诈。

上一期请参考&＃xff1a;科普 | 凭证真假难辨&＃xff0c;去中心化身份体系有妙招&＃xff08;二&＃xff09;

原文&＃xff1a;https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md

作者&＃xff1a;P. Dingle, S. Hammann, D. Hardman, C. Winczewski, S. Smit

 

                                                                                 验证者的最佳实践

在本节中&＃xff0c;我们将从 Alice 的故事中跳出来&＃xff0c;描述通常验证者应遵循的最佳做法&＃xff0c;以防止遭受恶意证书持有者的欺诈。我们将大致按照凭证验证过程的顺序来阐述相应的要点。

                                                                                                图 | 网络

• 验证者不应允许其他人来确认验证过程&＃xff08;或其一部分&＃xff09;。             

  • 持有人进行的验证不提供任何保证&＃xff1b;持有人可以使用欺诈性的软件&＃xff0c;使其看起来好像验证成功了。           

  • 验证者必须明确说明可接受的发行者和可接受的凭证模式&＃xff0c;并且必须确认展示的凭证符合这些要求。例如&＃xff0c;在测试到期时间时&＃xff0c;不得将月/日/年的编码模式与日/月/年的编码模式相混淆。            

  • 使用第三方验证者会使验证者受到影响&＃xff0c;任何人可能会和第三方验证者勾结&＃xff0c;或者第三方验证本身在存在漏洞。

• 验证者应将凭证持有者提供的数据视为不可信输入&＃xff0c;并执行适当的输入验证&＃xff0c;而不是假定这些数据拥有正确的凭证格式。             

  • 这是标准的安全编码做法&＃xff1a;必须对来自不受信任来源的任何输入进行合适的验证&＃xff0c;以防止发生例如代码注入或缓冲区溢出之类的攻击。            

  • 仅在成功进行输入验证之后&＃xff0c;才可执行可验证凭证的验证代码。            

• 验证者必须始终使用发行者的公钥进行签名验证&＃xff0c;或正确验证提供的零知识证明。

  • 需要特别说明的是&＃xff0c;忽略此检查绝不是使业务保持正常运行的一个可接受备选项&＃xff0c;例如&＃xff0c;当连接中断时忽略该检查。凭证欺诈所产生的潜在成本可能比短暂中断业务活动所产生的潜在成本高得多。

  • 虽然短时间内缓存发行者的公钥是可以接受的&＃xff0c;但作为最佳实践&＃xff0c;此缓存时间应短一些&＃xff0c;以防止使用旧公钥进行签名验证&＃xff08;例如&＃xff0c;由于旧密钥泄漏&＃xff0c;发行者可能已更换密钥&＃xff09;。      

• 验证者必须确保发行者在基础信任框架下已被授权可以发行这种类型的凭证。

  • 必须建立一个信任框架&＃xff0c;并明确定义相关规则&＃xff0c;如哪些发行者可以有效地发行哪种类型的凭证&＃xff0c;并且这些规则必须由验证者强制验证。            

• 验证者必须有一套明确定义的凭证接受标准。这包括但不限于确定证书属于持有人声称其所属的主体&＃xff08;通常是持有人本身&＃xff09;。             

  • 在“Alice 试图出售/出租她的凭证” 中概述了将可验证凭证绑定到主体的一些方法。请注意&＃xff0c;这是一个复杂的问题&＃xff0c;在本文的小节中并无法完全解决。            

  • 如果必须手动执行检查&＃xff0c;例如将照片与人的脸部进行比较&＃xff0c;则务必遵循精确的标准。

  • 我们描述了一种特殊类型的凭证&＃xff0c;该凭证只能显示一次&＃xff1b;其它凭证类型可能需要不同的域限定检查。信任框架务必明确定义验证者必须执行的其它检查。            

• 验证者必须检查凭证是否已过期并是否被吊销。             

  • 吊销检查涉及吊销列表&＃xff08;例如&＃xff0c;和存储发行人公钥的同一账本&＃xff09;。因此&＃xff0c;应采用与查找密钥相同的最佳做法&＃xff08;例如&＃xff0c;较短的缓存时间&＃xff09;。            

最佳实践列表并不详尽。毫无疑问&＃xff0c;更通用的建议是适当的。另外&＃xff0c;特定的最佳实践在特定行业或特定证明环境中可能很重要。

                                                                                               生存能力

我们的大多数讨论都采用了传统的网络安全思想&＃xff0c;强调漏洞及其对策。但是&＃xff0c;军事人员采用了以任务生存能力为基础的观点。在这种方法中&＃xff0c;问题不是“ 我们如何防止攻击&＃xff1f;” &＃xff0c;而是“ 面对活跃的攻击&＃xff0c;我们如何完成我们的任务&＃xff1f;”。在之前的 Alice 药房场景中&＃xff0c;药房的任务是根据法律/法规以可接受的方式按方配药&＃xff0c;这启发我们考虑影响结果的相互依存的三个因素&＃xff1a;

• 易受攻击性&＃xff08;攻击的可能性&＃xff09;             

• 脆弱性&＃xff08;给定一个攻击的情况下&＃xff0c;损害的可能性&＃xff09;             

• 可恢复性&＃xff08;在给定损害的情况下&＃xff0c;恢复的简便性和完全度&＃xff09;             

上面列出的大多数对策可解决脆弱性的问题&＃xff0c;但也有例外。生物特征识别和 link secret bond 机制不会直接阻碍凭证销售&＃xff08;降低脆弱性&＃xff09;&＃xff1b;相反&＃xff0c;它们通过破坏动机以减少被攻击的可能性。

该类技术可以在凭证场景中有广泛的应用。举个例子&＃xff0c;爱沙尼亚的在线投票系统允许每个公民随意投票多次&＃xff0c;但只计算最后一次投票。这就破坏了贿赂买选票的任何动机&＃xff0c;因为被贿赂的公民随后可以再次投&＃xff08;自己真正想要的&＃xff09;票&＃xff0c;从而消除了欺诈的影响并减少了被攻击的可能性。

                                                                                              图 | 网络

同样&＃xff0c;可恢复性的问题也值得深思。如果凭证欺诈能被快速自动地检测出来&＃xff0c;并进行撤消和惩罚&＃xff0c;那么即使最初的欺诈相对容易&＃xff0c;也能说明某些证明场景的保护是到位的。例如&＃xff0c;在我们的离线验证场景中&＃xff0c;为了快速分发救命药品&＃xff0c;可以适当放松对签名的实时性保证&＃xff0c;但是必须谨慎权衡恢复的时间和自动化性质。信任框架的存在可以确保已经仔细评估并公开记录这些折衷方案。

我们认为&＃xff0c;一个成熟且安全的可验证凭证生态系统应包括所有这三个维度相关的周全决策&＃xff0c;而不仅能脆弱性问题这一种。

                                                                                                  总结

我们可以看到 Alice 修改处方药或从其处方药中获利的尝试并未成功。在每个步骤中&＃xff0c;她试图篡改凭证或以超出预期的凭证欺诈行为都被检测出来&＃xff0c;并没有获得成功。药房充当了验证者&＃xff0c;通过遵循最佳实践&＃xff0c;确保了系统内的完整性并显著降低了风险。

值得注意的是&＃xff0c;尽管本文试图从持有者的角度确定许多可能的攻击方式&＃xff0c;但这绝不是针对当前或未来攻击的详尽描述。验证关键点的准确性和完整性的适当标准根据使用情况而有所不同。作者建议&＃xff0c;验证的任何实施者也应进行全面的风险分析&＃xff0c;并根据他们的特定需求进行分析。